Not a vault expert at all. But as far as I understand the the workspace scoped secrets need to be pre created in vault. How would one do that.

one option is for someone with permission to create at the correct path would have to create them with the relevant command, an admin user with their "access everything" policy

e.g. for kv, it would be something like vault kv put -mount=kv apps/coder/username/workspace/supersecret password=password

but more likely, the workspace user would generate a secret inside the workspace, and save it to vault (by running the above command in the workspace), and then it can never be retrieved from outside

policy could be created for allowing anyone access as long as they are accessing using a specific coder template

additionally, one of the scenarios im considering is an admin user who only has admin access from inside coder. policies granting full access to whatever, but only when authenticated with a specific mount/role, theres no specific secret, more just any and all secrets
(similar to how the only user with permission to create and manage auth methods and engines in my vault instance is a token generated by gitlab for a CI job in a specific repository, using exactly the same sort of configuration here)

something similar i already have set up, is that a specific k8s service account in the coder namespace is the only user capable of accessing the oidc client secret for coder, which is stored in vault
the disk pvc service account in k8s is the only user that can create or view disk encryption keys for the cluster, also in vault

another example of how this could be useful is allow you to use vault to generate k8s keys or aws access keys, but you can only do it from a trustworthy environment, you must be using template X

config difficult on the vault side
it can be as easy or difficult as the person managing it is willing to make it, assign an existing policy to the role, doesnt even need any configuration other than what they already have, or they can use every variable available
just because the variables are included in the token doesnt mean you have to use them in vault,
but if they're there, you have the option to use them if you want

additionally, this is just one of many many ways to set it up, you could have it generate with none of the fields and just authenticate the user, link the token to the user's entity in vault, 1:1 same permissions the user has outside, same secrets
or you can do more complex like what i'm using it for

but the ability to make complex policies based on data from the authentication source is exactly what you want with vault.

the difficulty is sorta similar to coder templates, if you wanted to you could make it so complicated and difficult to use, or you could make it easy, that's entirely up to the person who generates the token to pass to the module, and the person who writes the policies to decide what to do

I would appreciate it if we could also add a vault policy that can use this new jwt token

done, I added an example vault policy, as well as an example command for configuring the mount role

Hi @moo-im-a-cow can you run bun fmt?